home *** CD-ROM | disk | FTP | other *** search
- Path: ix.netcom.com!news
- From: giuliano@ix.netcom.com(Giuliano Carlini)
- Newsgroups: comp.lang.c++
- Subject: Re: static initialization order
- Date: 12 Apr 1996 17:30:15 GMT
- Organization: Netcom
- Message-ID: <4km3v7$7v5@dfw-ixnews6.ix.netcom.com>
- References: <Dppwqz.Kt3@undergrad.math.uwaterloo.ca>
- NNTP-Posting-Host: lbx-ca5-03.ix.netcom.com
- X-NETCOM-Date: Fri Apr 12 12:30:15 PM CDT 1996
-
- In <Dppwqz.Kt3@undergrad.math.uwaterloo.ca>
- sckettle@undergrad.math.uwaterloo.ca (Steve Kettle) writes:
- >
- >suppose you have n static objects that depend on each other. if the
- dependancy
- >graph is a forest ( a bunch of trees ) ( a tree is a graph with no
- cycles ) how
- >does one guarantee the correct order of construction? The objects in
- question
- >could be local to a number of different translation units.
- The draft standard states that static objects within a translation unit
- are constructed from top down and destructed bottom up. There is no
- specified order for static objects in different translation units, and
- the compiler writer may do so arbitrarilly.
-
- It would have been nice if C++ provided some mechanism to specify this.
-
- In these cases I avoid static objects, and replace them with static
- pointers to objects. At startup I initialize the pointers in dependency
- order.
-
- >that is my first question, second is i've been told that static data
- is often
- >located in memory addresses beyond the start of the heap. does this
- at all
- >contradict the fact that static data is initialzed to 0's at compile
- time?
-
- No. I'm not sure about this, but I believe the compiler is free to
- place static global objects where ever it chooses in memory. It simply
- must gaurantee that by the time main runs - actually a little before
- that - that uninitialized static data is set to 0.
-
- g
-